In today's increasingly connected world, applications must make faster and more complex decisions about what data to trust and what actions to take. These decisions can take into account information from many sources, which may vary in trustworthiness. It is desirable therefore for applications to have some information, especially critical information, in a form that can be verified as more trustworthy. Digital signatures have become widely deployed for this purpose.
Many of the uses of digital signatures can be considered as a type of assertion where one party, an issuer, makes a statement about another party, a subject, for use by a relying party such as an application. For example, a web server certificate is an assertion by a certification authority that a web server is associated with a given public key. The certification authority attaches its signature to the assertion so that other parties can verify that the certification authority made the assertion. Other examples include attribute certificates, which are statements issued by an attribute authority about one or more attributes of a subject; signed records in the Domain Name Security Extensions (“DNSSEC”), which are statements issued by a zone administrator about a domain name; and authentication assertions in the Security Assertion Markup Language (“SAML”).
With a signature, an assertion becomes transferable: any party can verify the authenticity of the assertion simply by applying the issuer's public key; the party does not need to interact with the issuer directly. For the same reason, a signed assertion is accountable: if the assertion's signature is valid, the issuer cannot deny that it made the assertion, but if the signature is not valid, then other parties cannot claim that the issuer made the assertion.
Despite the growing importance of assertions, there is no convenient way for a relying party to obtain the multifaceted set of assertions that it may need to perform its application logic, nor for issuers and subjects to manage this set. Current approaches are limited to certain types of information and do not necessarily provide the full confidence that applications may require. For example, a web server's certificate is readily obtained as part of process of setting up a secure connection with the server. However, it is not as straightforward to obtain an email user's certificate prior to sending a secure email to the user, or to obtain an assertion about a merchant's payment information prior to making a payment to the merchant, because connections to these parties—the subjects of the assertions—may not be available at the time the email is being sent or the payment is being made.
Furthermore, even when a relying party is able to obtain an assertion such as a certificate, it may not be clear that this is the assertion that the subject intends for the relying party to employ. This is a result of the fact that for a typical relying party, the signature on an assertion must be validated against a trust list, a set of public keys configured in the relying party's application. The signature typically must either be verifiable by a public key in the trust list, or by a public key certified through a chain of one or more certificates leading to a public key in the trust list. Because the trust list is large, there is a possibility that some of the participants in the trust hierarchy—any of which might be accepted as an assertion issuer—may be compromised. As a result, even though the actual issuer of a given assertion about a subject may not have been compromised, a different issuer might be able to produce an incorrect assertion about the subject, and absent other information, the relying party might accept it.
There have been some steps in the direction of a more convenient way for a relying party to obtain assertions that it can trust. For example, DNS-based Authentication of Named Entities (DANE) provides a way for a subject—in this case the party associated with a domain name—to publish its certificates in a standard location that is easy for a relying party to discover. Moreover, the subject—or the DNS zone administrator acting on behalf of it—can add its own signature to the record containing the certificate—a “countersignature”—to confirm, in a transferable way, that the certificate is indeed the one that the subject intends for the relying party to employ. Along with other features of DANE, this is a direct countermeasure to the problem just mentioned where a different issuer attempts to present an alternate certificate in place of the actual one. Despite these advantages, DANE as currently specified is still limited by the lack of several characteristics that may be important in new applications.